Skip to content

feat(core) Support multiple event managers (multi-canvas prep)#10375

Open
ibgreen-openai wants to merge 2 commits into
masterfrom
ib/multi-canvas-event-manager-prep
Open

feat(core) Support multiple event managers (multi-canvas prep)#10375
ibgreen-openai wants to merge 2 commits into
masterfrom
ib/multi-canvas-event-manager-prep

Conversation

@ibgreen-openai

@ibgreen-openai ibgreen-openai commented Jun 12, 2026

Copy link
Copy Markdown
Collaborator

Summary

Prepare the multi-canvas RFC by landing the view-scoped event-manager routing seam separately from the full rendering work.

Why

The follow-up ib/multi-canvas-rfc branch needs per-canvas EventManager instances, but the event-manager / Mjolnir.js-facing part is easier to review independently from CanvasManager, presentation contexts, render/pick changes, and React multi-canvas DOM structure.

This prep diff is behavior-preserving on master: Deck still creates and uses the existing singleton EventManager, but Deck and ViewManager now route through a stable canvas-id seam so the RFC branch can later provide distinct managers per presentation canvas.

What changed

  • Added latent canvasId?: string view identity plumbing.
  • Added ViewManager.getCanvasId(viewOrViewId) with a stable default-canvas fallback.
  • Factored Deck's existing singleton EventManager creation and stored it in eventManagers under the default canvas id.
  • Added Deck.getEventManager(viewId?: string); on this prep branch it still resolves the current singleton.
  • Passed eventManagers into ViewManager and routed controller creation through each view's resolved canvas id/event manager binding.
  • Recreate controllers only when a view's canvas id or mapped event manager changes.
  • Updated React positioning context to use the public deck.getEventManager(viewId) seam.
  • Added focused Deck, ViewManager, and React tests for the new seam.

Intentionally not included

  • No CanvasManager.
  • No DeckProps.canvases.
  • No presentation contexts or canvas metrics.
  • No multi-canvas render, pick, or DOM event routing.
  • No React multi-canvas host or portal changes.

Validation

  • yarn build
  • yarn test-headless test/modules/core/lib/view-manager.spec.ts test/modules/core/lib/deck.spec.ts
  • yarn test-headless test/modules/react/utils/position-children-under-views.spec.ts test/modules/react/deckgl.spec.ts
  • yarn lint

yarn lint passes with warnings only. The focused React test still emits the existing act(...) warning while passing.

@coveralls

coveralls commented Jun 12, 2026

Copy link
Copy Markdown

Coverage Status

coverage: 83.442% (+0.02%) from 83.424% — ib/multi-canvas-event-manager-prep into master

@ibgreen-openai ibgreen-openai changed the title [codex] Prepare multi-canvas event manager routing feature: Support multiple event managers (multi-canvas prep) Jun 12, 2026
@ibgreen-openai ibgreen-openai changed the title feature: Support multiple event managers (multi-canvas prep) feat(core): Support multiple event managers (multi-canvas prep) Jun 12, 2026
@ibgreen-openai ibgreen-openai changed the title feat(core): Support multiple event managers (multi-canvas prep) feat(core) Support multiple event managers (multi-canvas prep) Jun 12, 2026
@ibgreen-openai ibgreen-openai marked this pull request as ready for review June 12, 2026 17:27
@ibgreen-openai ibgreen-openai force-pushed the ib/multi-canvas-event-manager-prep branch from 85cee04 to ff8fefb Compare June 15, 2026 16:43

@charlieforward9 charlieforward9 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A very powerful addition for the new thor.gl frontier I will be presenting at the summit! 🚀

/**
* Get the event manager associated with a view or the default Deck canvas.
*/
getEventManager(viewId?: string): EventManager | null {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should console.warn. Fallback makes sense but should be a little less silent on a public method.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should console.warn. Fallback makes sense but should be a little less silent on a public method.

While it would be nice to show developer friendly messages all over the API in cases like this, such message strings would all be adding to the bundle size of the application and since they have no value to end user, we generally avoid adding them unless value is very high.

}

private _createEventManager(root: HTMLElement): EventManager {
const eventManager = new EventManager(root, {

@charlieforward9 charlieforward9 Jun 15, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@chrisgervang does it make sense to refactor my recent mobile tip+tricks work:

CSS guards on the Deck canvas/root element

within cssProps here (rather than forcing user to workaround with external CSS)?

| {[viewId: string]: AnyViewStateOf<ViewsT>};

/** Canvas id used by views that do not declare a presentation canvas. */
export const DEFAULT_CANVAS_ID = 'default-canvas';

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/**
* Optional id of the presentation canvas associated with this view.
* Integrations that render views into multiple canvases can use this id to route view-scoped
* resources such as event managers.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* resources such as event managers.
* resources such as event managers. Default: `default-canvas`

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants